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REMARKS 

Claims 1-13 are pending in the application, of which Claims 1,11 and 13 are independent 
claims. Claims 1, 7-9 and 11-13 are rejected under 35 U.S.C. § 102(e). Claims 2-6 and 10 are 
rejected under 35 U.S.C. § 103(a). Claims 1, 2, 3 5, 8, 1 1 and 13 have been amended to more 
distinctly claim the Applicants' claimed invention and to be consistent with the language used in 
the remainder of the claims. New Claim 14-52 have been added. The application is also subject 
to objections. 

Disclosure Objections 

As noted by the Examiner, the application numbers of co-pending applications were not 
specified on the application because those applications were filed on even date with the subject 
application. In response, the specification has been amended to specify those application 
numbers. No new matter is being added to the application. 

Acceptance of the amendments and withdrawal of the objection is respectfully requested. 

Claim Objections 

Claim 12 is objected to based on informalities. As suggested by the Examiner, the 
Applicants have amended Claim 12 to depend from Claim 11. 

Acceptance of the amendment and withdrawal of the objection is respectfully requested. 

Rejections under 35 U.S.C. § 102(e) 

Claims 1, 7-9 and 1 1-13 are rejected under 35 U.S.C. § 102(e) based on U.S. Patent No. 
6,092,213 to Lennie. This rejection is traversed. The claims, however, have been amended to 
more distinctly claim the subject matter of the Applicants' invention. These amendments are not 
an acquiescence to the rejection. The Applicants respectfully submit that Lennie neither 
discloses nor suggests the claimed invention. 

"A prima facie rejection based on anticipation requires that each and every element as set 
forth in the claim is found, either expressly or inherently described, in a single prior art 
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reference "//i re Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999). 
That is, the prior art reference must disclose each and every element of the claim with sufficient 
clarity to prove its existence in the prior art. In re Spada, 911 F,2d 705, 708, 15 U.S. P. Q. 2D 
(B.N.A.) 1655, 1657 (Fed. Cir. 1990) ("The [prior art] reference must describe the applicant's 
claimed invention sufficiently to have placed a person of ordinary skill in the field of the 
invention in possession of it" [emphasis added] (citations omitted)). Here, the Office has not set 
forth a prima facie showing of anticipation. 

The Applicants claim a technique for maintaining a cluster definition for a network 
cluster. The network cluster has at least one member node that is coupled to a shared repository. 
A cluster definition for the network cluster is stored in the shared repository. A coordinator node 
is selected from the at least one member node. A member node requests a change to the cluster 
definition by sending a proposed change the shared repository. In response to the proposed 
change request, the coordinator node updates the cluster definition to reflect the requested 
change, 

hi contrast, Lennie discusses an approach for maintaining a cluster configuration and 
distributing the cluster configuration to nodes of the cluster. According to Lennie, a request to 
change the cluster configuration is received by a primary process running on one of the nodes. 
The primary process stores the configuration changes on a database registry and communicates 
the configuration changes to each node. When a node receives the configuration changes from 
the primary process, a monitor process running on the node stores the configuration changes in a 
database registry associated with the node. 

To begin with, Lennie neither discloses nor suggests the Applicants' claimed invention. 
In particular, the Applicants' claimed shared repository requires: 

• storing a cluster definition in the shared repository : 

• a member node requesting a change to the cluster definition by sending a 
proposed change the shared repository ; and 

• updating , from the coordinator node, the cluster definition stored in the shared 
repository to reflect the requested change . 
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Although, Lennie discusses repositories that store cluster configuration data, none of the 
repositories discussed in Lennie include all the claimed limitations of the Applicants' claimed 
shared repository. That is, in Lennie: i) repositories are not shared, ii) a member node is not 
requesting a change by sending a proposed change to the shared repository, and iii) a coordinator 
node is not updating the cluster definition stored in the shared repository. 

Instead of using a shared repository to store a cluster definition, Lennie discusses that 
each node has its own repository. In fact, there is no indication in Lennie that any of repositories 
are shared or used by more than one node. In Figure 2, Lennie depicts a flow diagram of the 
interrelationships between nodes, repositories (databases / registries) and processes. For 
illustrative purposes, Lennie's Figure 2 is shown below. 




na z 

According to Lennie, the primary process (P-TMP) running on Node 0 (12 0 .) is 
responsible for receiving cluster configuration changes and distributing the changes to each node 
(the arrows in Figure 2 illustrate this distribution flow). For example, the primary process (P- 
TMP) writes the changes both to a master audit log (MAT) in a repository associated with Node 
0 (12 0 .) and to a mirrored copy of the master audit log (MAT 7 ) in another repository associated 
with Node 0 (12 0 ). Then, the primary process (P-TMP) distributes the changes to each node. 
Each node has a monitor process (MON) that receives the changes and writes the changes to the 
node's associated database registry. For instance, the monitor process running on Node 1 (12,.) 
sends the changes to a registry (16 4 ) associated with the Node 1 (12 r ). Thus, each node has its 
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own repository and none of the nodes in Lennie are sharing or using the same repository. As 
such, Lennie does not discuss anything about a shared repository as claimed by the Applicants. 

Not only does Lennie fail to suggest a shared repository, but Lennie teaches away from 
the claimed invention. By using local repositories, Lennie has no need for a shared repository. If 
Lennie were to employ a shared repository then there would be no need to copy data to each 
node, as discussed by Lennie. 

In particular, Lennie teaches that a node should have its own "safe repository" to keep 
cluster configuration data safe from corruption. As such, Lennie does not suggest using a shared 
repository. A shared repository would be inconsistent with Lennie's approach to maintaining 
configuration data because by suggesting that it is safer for each node to have its own repository 
to store configuration data, Lennie discourages nodes from sharing repositories. Thus, Lennie's 
approach is contrary to the Applicants' claimed invention, which requires a shared repository to 
store a cluster definition. 

Furthermore, Lennie neither discloses nor suggests the Applicants' claimed member node 
requesting a change to the cluster definition by sending a proposed change to the shared 
repository. In fact, Lennie's approach to maintaining and distributing cluster configuration data 
is not directed to requesting a change . Specifically, Lennie relates to a primary process that 
maintains and distributes cluster configuration changes after the changes have been received. In 
fact, Lennie provides very little insight regarding the details of configuration changes before they 
have been received by the primary process. One of the few details Lennie provides is that 
transaction monitoring is used to detect configuration changes. See Lennie, col. 4, 11. 48-59. 
Thus, Lennie does not discuss anything about a member node requesting a change to the cluster 
definition by sending a proposed change to the shared repository, and as a result, Lennie does not 
discuss the limitations and advantages of the claimed invention. 

In particular, by requiring that each member node send its proposed change to a shared 
resource, the Applicants' invention can avoid a situation in which multiple nodes are trying to 
make changes to the cluster definition in parallel. Parallel edits can result in a cluster definition 
that partially represents changes made by a first node and partially represents changes made by a 
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second node. The resulting cluster definition is not representative of either node's proposed 
definition. See Specification, pg. 14, 11. 25 - pg. 15, 11. 2. 

Lennie's approach to maintaining cluster configuration does not contemplate such 
problems associated with multiple member nodes proposing changes to a cluster definition. 
Indeed, Lennie does not suggest the Applicants' claimed member node requesting a change to the 
cluster definition by sending a proposed change to a shared repository. As such, Lennie neither 
discloses the requirements nor the advantages of the Applicants' claimed invention. 

Thus, the Applicants' claimed invention requires certain limitations that are neither 
disclosed nor suggested by Lennie. In short, Lennie does not discuss the Applicants' claimed: 



As such, the Office has not established a prima facie showing of anticipation. 

Claims 7 and 9 depend from base Claim 1, and Claim 12 depends from base Claim 1 1 
and have been rejected under 35 U.S.C. § 102(e). As the dependent claims incorporate all 
limitations from the corresponding base claim, allowance of the dependent claims follows from 
allowance of the base claim. Because the base claim are in condition for allowance, the 
dependent claims should also be allowed. Reconsideration of the rejections under 35 U.S.C. § 
102(e) is respectfully requested. 

Accordingly, for each claim rejection under 35 U.S.C. § 102(e), the Office has not 
established a prima facie showing of anticipation. As such, the Office has not met its burden in 
establishing a prima facie case under 35 U.S.C. § 102(e). Consequently, the rejections under of 
Claims 1, 11 and 13 under 35 U.S.C. §102(e) should be removed. 
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coupling the at least one member node to a shared repository; 
storing a cluster definition for the network cluster in the shared 

repository; 

a member node requesting a change to the cluster definition by 
sending a proposed change to the shared repository; and 
the coordinator node updating the cluster definition stored in the 
shared repository to reflect the requested change. 
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Rejections of Claims under 35 U.S. C. § 103 fa) 

Claims 2-6 and 10 depend from base Claim 1, and have been rejected under 35 U.S.C. § 
103(a). Specifically, Claims 2, 3 and 10 are rejected under 35 U.S.C. § 103(a) based on U.S. 
Patent No. 6,092,213 to Lennie in view of U.S. Patent No. 6, 014,669 to Slaughter. Claim 4 is 
rejected under 35 U.S.C. § 103(a) based on Lennie in view of U.S. Patent No. 6,003,075 to 
Arendt. Claim 5 is rejected under 35 U.S.C. § 103(a) based on U.S. Patent No. 6,092,213 to 
Lennie in view of U.S. Patent No. 5,964,886 to Slaughter. Claim 6 is rejected under 35 U.S.C. § 
103(a) based on Lennie and Slaughter in view of U.S. Patent No. 6,243,702 to Bramford. 

As the dependent claims incorporate all limitations from the corresponding base claim, 
allowance of the dependent claims follows from allowance of the base claim. Because the base 
claim are in condition for allowance, the dependent claims should also be allowed. 

Even if the independent claims are not allowed, the Applicants respectfully submit that 
the references taken alone or in combination neither disclose or suggest the Applicants' claimed 
invention. For brevity, the Applicants will only highlight certain areas where the Office has 
failed to make a prima facie showing of obviousness under 35 U.S.C. § 103(a). 

Addressing Claim 2, the Office has not made a prima facie showing of obviousness under 
35 U.S.C. § 103(a) because neither Lennie nor Slaughter, take separately or in combination, 
disclose the requirements of the claimed invention. Specifically, neither reference disclose or 
suggest the Applicants' claimed member node requesting a change to the cluster definition stored 
in a shared repository including, sending a proposed change to a scratch area of the shared 
repository and setting a valid bit associated with the scratch area. In fact, there is no discussion 
in either reference regarding the Applicants' claimed techniques for requesting a change to the 
cluster definition. 

Like Lennie, Slaughter discusses an approach to implementing a change to a cluster 
configuration, but does not discuss a technique for requesting a change. Further, neither Lennie 
nor Slaughter discuss the Applicants' claimed setting a valid bit associated with a scratch area in 
the shared repository. In fact, neither Lennie nor Slaughter even suggest that a scratch area of a 
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shared repository exists. Thus, the references do not disclose the limitations of Applicants' 
Claim 2. 

Addressing Claim 5, the Office has not made a prima facie showing of obviousness under 
35 U.S.C. § 103(a). To begin with, the Office did not provide any motivation to combine Lennie 
and Slaughter absent hindsight. "Knowledge of applicant's disclosure must be put aside in 
reaching., [a].. determination [of obviousness]." See M.P.E.P. § 2142. "[T]he examiner must step 
backward in time and into the shoes worn by the hypothetical 'person of ordinary skill in the art' 
when the invention was unknown and just before it was made. In view of all factual information 
the examiner must then make a determination whether the claimed invention 'as a whole' would 
have been obvious at that time to that person. . . . Impermissible hindsight must be avoided and 
the legal conclusion must be reached on the facts gleaned from the prior art." In re Glaug, 283 
F.3d 1335, 1338, 62 U.S.P.Q.2d 1151, 1 152 (Fed. Cir. 2002). Indeed, the Office has not relied 
on any facts gleaned on from the prior art to provide motivation to combine the references. 

Moreover, the references do not provide a reasonable expectation of success. 
Specifically, the references do not enable one skilled in the art to achieve the Applicants' claimed 
invention. A prior art reference is not enabling when it provides "only general guidance as to the 
particular form of the claimed invention or how to achieve it." (Citations omitted; internal 
quotations omitted). In re Roemer, 258 F.3d 1303, 1310, 59 U.S.P.Q.2d (B.N.A.) 1527, 1533 
(Fed. Cir. 2001) (requiring that the prior art disclosure suggest a reasonable probability of 
success). The combination of Lennie and Slaughter does not enable one to achieve the 
Applicants' claimed invention as set forth in Claim 5 because neither reference discusses 
anything about potential member nodes that are requesting membership in the cluster and 
accessing the cluster definition stored in the shared repository . In particular, neither reference 
discusses anything about accessing, by a potential member node, the cluster definition stored in 
the shared repository. 

Furthermore, the references do not discuss the limitations and advantages of Claim 5. 
Claim 5 requires requesting, by a potential member node, membership in the network cluster, and 
accessing, by the potential member node, the cluster definition. As such, the Applicants' claimed 



OID-1999-35-04 



-25- 



09/322,472 



technique advantageously allows a potential member node that does not have connectivity with 
the network cluster to receive the cluster definition by accessing the shared repository. See 
Specification, pg. 12, 11. 25-27. 

Like other prior art systems, Lennie and Slaughter discuss an approach to distributing 
cluster configuration data, in which a node needs connectivity with a cluster in order to receive 
the cluster configuration. According to Lennie, any change to the cluster configuration is 
received by a primary process running on one of the nodes, which in turn, stores these changes on 
a database registry and communicates these changes to the other nodes. As a result, the nodes 
must have connectivity with the cluster in order to receive the configuration changes from the 
primary process. 

Likewise, Slaughter discusses an approach in which network connectivity is required for 
a node to receive a cluster configuration. In particular, Slaughter teaches to implement a virtual 
disk operating on the nodes of a cluster, in which a distributed program monitors membership 
changes and conveys the membership changes to other programs running on the nodes in the 
cluster. Rather than discussing the Applicants' claimed shared repository, Slaughter discusses a 
shared virtual disk executing in the network cluster. The virtual disk in Slaughter uses several 
distributed programs to implement configuration changes across the cluster. As such, network 
connectivity is required for a node to receive a cluster configuration. Thus, Slaughter does not 
discuss anything about the Applicants' claimed accessing, by a potential member node, the 
cluster definition stored in the shared repository, and requesting, by the potential member node, 
membership in the cluster. As such, Slaughter neither discusses the requirements nor advantages 
of the Applicants' claimed invention. 

Instead of requiring that a node have connectivity with the network cluster to receive a 
cluster configuration, the Applicants' claimed technique advantageously allows a node that does 
not have connectivity with the network cluster to receive an updated cluster definition when 
accessing the shared repository. See Specification, pg. 12, 11. 25-27. Thus, neither Lennie nor 
Slaughter use a shared repository in which a node can access the cluster definition. Rather than 
using a shared repository, both Lennie and Slaughter distribute a cluster definition to the nodes of 
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the cluster. As such, the references neither disclose the advantages nor requirements of the 
claimed invention. 

In order to establish a prima facie showing of obviousness, three basic criteria must be 
met, as described in M.P.E.P. § 2142: 

(1) There must be some suggestion, or motivation, to modify the reference or 
combine the reference teachings; 

(2) There must be a reasonable expectation of success; and 

(3) . The prior art reference, or combined references, must teach or suggest all 

the claim limitations. 
Thus, for each claim rejection under 35 U.S. C. § 103(a) the Office has not 
established a prima facie showing of obviousness. First, the Office has not shown that the 
references disclose the limitations of the claimed invention. Second, the Office has not shown 
that the references provide a reasonable expectation of success. Specifically, the references do 
not enable one skilled in the art to achieve the Applicants' claimed invention. A prior art 
reference is not enabling when it provides "only general guidance as to the particular form of the 
claimed invention or how to achieve it." (Citations omitted; internal quotations omitted). In re 
Roemer, 258 F.3d 1303, 1310, 59 U.S.P.Q.2d (B.N. A.) 1527, 1533 (Fed. Cir. 2001) (requiring 
that the prior art disclosure suggest a reasonable probability of success). Finally, the Office has 
not provided any suggestion or motivation to combine the references. Accordingly, the Office 
has not met its burden in establishing a prima facie showing of obviousness under 35 U.S.C. 
§103(a). 

Reconsideration of the rejections under 35 U.S.C. § 103(a) is respectfully requested. 
New Claims 

New Claims 14-52 are being added to the application to more distinctly claim the 
Applicants' claimed invention. No new matter is being introduced. Acceptance and allowance 
are respectfully requested. 
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Information Disclosure Statement 

An Information Disclosure Statement (IDS) is being filed concurrently herewith. Entry of 
the IDS is respectfully requested. 

CONCLUSION 

In view of the above amendments and remarks, it is believed that all claims are in 
condition for allowance, and it is respectfully requested that the application be passed to issue. If 
the Examiner feels that a telephone conference would expedite prosecution of this case, the 
Examiner is invited to call the undersigned attorney at (978) 341-0036. 

Respectfully submitted, 

HAMILTON, BROOK, SMITH & REYNOLDS, P.C. 





B y ^~^<^p O _ 
Rodney D.<*£6^nson 
Registration No. 36,558 
Telephone: (978) 341-0036 
Facsimile: (978)341-0136 



Concord, MA 01742-9133 
Dated: 4 . , 
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Specification Amendments Under 37 C.F.R. $ 1.121(b¥l¥iin 



Replace the paragraph at page 1, lines 8 through 18 with the below paragraph marked up 
by way of bracketing and underlining to show the changes relative to the previous version of the 
paragraph. 

Serial No. [ 1 09/321,090 , filed May 28, 1999, entitled A QUORUMLESS 

CLUSTER USING DISK-BASED MESSAGING, by Richard Frank, Michael Cusson, Joydip 
Kundu, and Daniel E. O'Shaughnessy, inventors; 

Serial No. { 1 09/32L998 . filed May 28, 1999, entitled AVOIDING N-SQUARED 

HEARTBEAT MESSAGING PROBLEM IN AN OPERATING CLUSTER VIA CLOSED LOOP 
MESSAGING THEME, by Richard Frank, Michael Cusson, Joydip Kundu, and Daniel E. 
O'Shaughnessy, inventors; and 

Serial No. [ 1 09/321.967 . filed May 28, 1999, entitled PROVIDING FIGURE OF 

MERIT VOTE FROM APPLICATION EXECUTING ON A PARTITIONED CLUSTER, by 
Richard Frank, Michael Cusson, Joydip Kundu, and Daniel E. O'Shaughnessy, inventors. 

Replace the paragraph at page 10, lines 21 through 26 with the below paragraph marked up 
by way of bracketing and underlining to show the changes relative to the previous version of the 
paragraph. 

As described above in conjunction with FIG. 2, the cluster manager 32, in concert with the 
cluster managers residing on [nodes_ 2 - 4] nodes 2 - node 4 14, 16, 18, manages cluster 
connectivity within the quorumless cluster 10. For the cluster managers to effectively cooperate in 
the connectivity management endeavor, a facility for sharing data is provided. The shared storage 
device 22 of FIG. 1 houses a repository for this data sharing facility. 
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Replace the paragraph at page 24, lines 5 through 24 with the below paragraph marked up 
by way of bracketing and underlining to show the changes relative to the previous version of the 
paragraph. 

A quorumless network cluster [is described which] provides a highly available system by 
addressing the partition-in-space and partition-in-time problems in network clusters. 

[This solution provides a] In a particular solution, a cluster manager (CM) [which uses] can 
use disk based messaging to manage the operation of the cluster. Each node within the cluster must 
have access to a shared disk to operate within the cluster. [In the case of a partition-in-space 
problem, where a subset of nodes maintains full network connectivity among the nodes within the set 
but has no connectivity between the sets, the CM queries an application, operating on the cluster, to 
provide input to the CM to select which subset of nodes will survive as the cluster. ] 

[Also described is a] A particular methodology [for operating] can operate the cluster in a 
closed loop between nodes 1 to N. [Each node sends a single heartbeat message to the node ahead of 
it in the loop and receives a single heartbeat message from the node behind it in the loop.] If a node 
fails to receive a heartbeat message from its predecessor in the loop, it initiates a cluster 
reconfiguration by sending a reconfiguration message to each other node in the cluster. 

The quorumless cluster [also provides] can also include a common storage for a cluster 
definition. [A single node is designated as the coordinator node of the cluster.] Each node may 
provide a proposed change to the cluster definition however only [the] a single coordinator node 
may update the cluster definition and apply the suggested changes. 
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Claim Amendments Under 37 C.F.R. § lA2l(c)(l)(ii) 

1 . (Amended) A method for maintaining a cluster definition for a network cluster having at 
least one member node, the method comprising: 

coupling the at least one member node to a [shareable] shared repository; 
storing a cluster definition for the network cluster in the [shareable] shared 
repository; 

selecting a coordinator node from the at least one member node of the network 

cluster; 

at a member node a requesting a change to the cluster definition by sending a proposed 
change to the shared repository ; and 

in response to the proposed change request, updating, from the coordinator node A 
[updating] the cluster definition stored in the shared repository to reflect the requested 
change. 



2. (Amended) The method of Claim 1 wherein requesting a change to the cluster definition 
includes: 

sending [a] the proposed change to a scratch area of the shared repository ; and 
setting a valid bit associated with the scratch area of the shared repository . 

3. (Amended) The method of Claim 2 wherein updating the cluster definition includes: 

verifying the valid bit; 
setting an update flag; 

modifying the cluster definition to reflect the requested change; 
logging a progress of modifying the cluster definition in a log file in parallel with 
modifying the cluster definition; 

incrementing a version number associated with the [shareable] shared repository; and 
clearing the valid bit and the update flag. 
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5. (Amended) The method of Claim 1 further comprising: 

requesting, by a potential member node, membership in the network cluster; and 
accessing, by the potential member node, the cluster definition stored in the shared 
repository . 

8. (Amended) The method of Claim 7 wherein recovering includes: 

selecting a new coordinator node from the member nodes of the network cluster[,]; 

and 

completing, by the new coordinator node, an update of the cluster definition to reflect 
the requested change if there is a set valid bit and an incomplete log file in the [shareable] 
shared repository. 

1 1 . (Amended) An apparatus for updating a cluster definition for a network cluster 
having at least one member node, comprising: 

a [shareable] shared repository coupled to the at least one member node of the 
cluster, the repository including the cluster definition and a proposed change to the cluster 
definition; and 

a coordinator node, selected from the at least one member node of the network 
cluster, to update the cluster definition with the proposed change. 

12. (Amended) The apparatus of Claim [12] H further including: 

a log file, indicating a progress of updating the cluster definition. 
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13. (Amended) A computer program product for maintaining a cluster definition for a network 
cluster having at least one member node, the computer program product comprising: 



a computer usable medium having computer readable program code thereon, 
including program code [which] for: 

[couples] coupling the at least one member node to a [shareable] shared 
repository; 

[stores] storing a cluster definition for the network cluster in the [shareable] 
shared repository; 

[selects] selecting a coordinator node from the at least one member node of 
the network cluster; and 

[directs] directing the coordinator node to update the cluster definition in 
response to a request to change the cluster definition [to reflect a requested change]. 
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